WebGL Query Objects: การวัดประสิทธิภาพและการทำโปรไฟล์ระดับปรมาจารย์สำหรับนักพัฒนาระดับโลก

ในโลกของเว็บกราฟิกที่มีการเปลี่ยนแปลงตลอดเวลา การสร้างประสบการณ์ที่ราบรื่น ตอบสนองได้ดี และสวยงามตระการตาถือเป็นสิ่งสำคัญยิ่ง ไม่ว่าคุณจะกำลังพัฒนาเกม 3D ที่สมจริง การแสดงข้อมูลแบบอินเทอร์แอคทีฟ หรือการนำเสนอสถาปัตยกรรมที่ซับซ้อน ประสิทธิภาพคือกุญแจสำคัญ ในฐานะนักพัฒนา เรามักจะอาศัยสัญชาตญาณและแนวทางปฏิบัติที่ดีที่สุดทั่วไปเพื่อเพิ่มประสิทธิภาพแอปพลิเคชัน WebGL ของเรา อย่างไรก็ตาม เพื่อให้เป็นเลิศอย่างแท้จริงและรับประกันประสบการณ์คุณภาพสูงที่สม่ำเสมอสำหรับผู้ชมทั่วโลกบนฮาร์ดแวร์ที่หลากหลาย ความเข้าใจที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับเมตริกประสิทธิภาพและเทคนิคการทำโปรไฟล์ที่มีประสิทธิภาพจึงเป็นสิ่งจำเป็น และนี่คือจุดที่ WebGL Query Objects เข้ามามีบทบาทสำคัญ

WebGL Query Objects เป็นกลไกที่มีประสิทธิภาพในระดับต่ำสำหรับสอบถามข้อมูลโดยตรงจาก GPU เกี่ยวกับแง่มุมต่างๆ ของการทำงาน โดยเฉพาะอย่างยิ่งข้อมูลเกี่ยวกับเวลา ด้วยการใช้ออบเจ็กต์เหล่านี้ นักพัฒนาสามารถได้รับข้อมูลเชิงลึกอย่างละเอียดว่าคำสั่งหรือลำดับการเรนเดอร์ที่เฉพาะเจาะจงใช้เวลาในการประมวลผลบน GPU นานเท่าใด ซึ่งจะช่วยระบุคอขวดด้านประสิทธิภาพที่อาจซ่อนอยู่ได้

ความสำคัญของการวัดประสิทธิภาพ GPU

แอปพลิเคชันกราฟิกสมัยใหม่ต้องพึ่งพาหน่วยประมวลผลกราฟิก (GPU) เป็นอย่างมาก ในขณะที่ CPU จัดการกับตรรกะของเกม การจัดการฉาก และการเตรียม draw calls แต่ GPU คือส่วนที่ทำงานหนักในการแปลงค่าพิกัด (vertices) การแรสเตอร์ (rasterizing) ส่วนย่อย การใช้เท็กซ์เจอร์ และการคำนวณเฉดสีที่ซับซ้อน ปัญหาด้านประสิทธิภาพในแอปพลิเคชัน WebGL มักเกิดจากการที่ GPU ทำงานหนักเกินไปหรือถูกใช้งานอย่างไม่มีประสิทธิภาพ

การทำความเข้าใจประสิทธิภาพของ GPU มีความสำคัญอย่างยิ่งด้วยเหตุผลหลายประการ:

• การระบุคอขวด (Identifying Bottlenecks): แอปพลิเคชันของคุณช้าเพราะเชเดอร์ที่ซับซ้อน, draw calls ที่มากเกินไป, แบนด์วิดท์ของเท็กซ์เจอร์ไม่เพียงพอ หรือการวาดทับ (overdraw) หรือไม่? Query objects สามารถช่วยชี้ชัดได้ว่าขั้นตอนใดในไปป์ไลน์การเรนเดอร์ของคุณที่ทำให้เกิดความล่าช้า
• การเพิ่มประสิทธิภาพกลยุทธ์การเรนเดอร์ (Optimizing Rendering Strategies): เมื่อมีข้อมูลเวลาที่แม่นยำ คุณจะสามารถตัดสินใจได้อย่างมีข้อมูลว่าจะใช้เทคนิคการเรนเดอร์แบบใด ควรลดความซับซ้อนของเชเดอร์ ลดจำนวนโพลีกอน เพิ่มประสิทธิภาพรูปแบบเท็กซ์เจอร์ หรือใช้กลยุทธ์การคัดกรอง (culling) ที่มีประสิทธิภาพมากขึ้น
• การรับประกันความสอดคล้องข้ามแพลตฟอร์ม (Ensuring Cross-Platform Consistency): ความสามารถของฮาร์ดแวร์แตกต่างกันอย่างมากในแต่ละอุปกรณ์ ตั้งแต่ GPU บนเดสก์ท็อประดับไฮเอนด์ไปจนถึงชิปเซ็ตมือถือที่ใช้พลังงานต่ำ การทำโปรไฟล์ด้วย query objects บนแพลตฟอร์มเป้าหมายจะช่วยให้แน่ใจว่าแอปพลิเคชันของคุณทำงานได้อย่างเพียงพอในทุกที่
• การปรับปรุงประสบการณ์ผู้ใช้ (Improving User Experience): อัตราเฟรมที่ราบรื่นและเวลาตอบสนองที่รวดเร็วเป็นพื้นฐานของประสบการณ์ผู้ใช้ที่ดี การใช้ GPU อย่างมีประสิทธิภาพส่งผลโดยตรงต่อประสบการณ์ที่ดีขึ้นสำหรับผู้ใช้ของคุณ โดยไม่คำนึงถึงตำแหน่งหรืออุปกรณ์ของพวกเขา
• การเปรียบเทียบและการตรวจสอบ (Benchmarking and Validation): สามารถใช้ Query objects เพื่อเปรียบเทียบประสิทธิภาพของคุณสมบัติการเรนเดอร์ที่เฉพาะเจาะจง หรือเพื่อตรวจสอบประสิทธิผลของความพยายามในการเพิ่มประสิทธิภาพ

หากไม่มีเครื่องมือวัดโดยตรง การปรับแต่งประสิทธิภาพมักจะกลายเป็นกระบวนการลองผิดลองถูก ซึ่งอาจใช้เวลานานและอาจไม่นำไปสู่ทางออกที่ดีที่สุดเสมอไป WebGL Query Objects นำเสนอแนวทางทางวิทยาศาสตร์ในการวิเคราะห์ประสิทธิภาพ

WebGL Query Objects คืออะไร?

WebGL Query Objects ซึ่งส่วนใหญ่เข้าถึงผ่านฟังก์ชัน createQuery() โดยพื้นฐานแล้วเป็นตัวชี้ไปยังสถานะที่อยู่บน GPU ซึ่งสามารถสอบถามข้อมูลประเภทเฉพาะได้ ประเภทคิวรีที่ใช้บ่อยที่สุดสำหรับการวัดประสิทธิภาพคือ เวลาที่ผ่านไป (time elapsed)

ฟังก์ชันหลักที่เกี่ยวข้องคือ:

• gl.createQuery(): สร้าง query object ใหม่
• gl.deleteQuery(query): ลบ query object และปลดปล่อยทรัพยากรที่เกี่ยวข้อง
• gl.beginQuery(target, query): เริ่มการสอบถาม target ระบุประเภทของการสอบถาม สำหรับการจับเวลา โดยทั่วไปจะเป็น gl.TIME_ELAPSED
• gl.endQuery(target): สิ้นสุดการสอบถามที่ทำงานอยู่ จากนั้น GPU จะบันทึกข้อมูลที่ร้องขอระหว่างการเรียก beginQuery และ endQuery
• gl.getQueryParameter(query, pname): ดึงผลลัพธ์ของคิวรี pname ระบุพารามิเตอร์ที่จะดึงข้อมูล สำหรับการจับเวลา โดยทั่วไปจะเป็น gl.QUERY_RESULT ผลลัพธ์มักจะอยู่ในหน่วยนาโนวินาที
• gl.getQueryParameter(query, gl.GET_QUERY_ PROPERTY): นี่เป็นฟังก์ชันทั่วไปมากขึ้นในการรับคุณสมบัติต่างๆ ของคิวรี เช่น ผลลัพธ์พร้อมใช้งานแล้วหรือไม่

เป้าหมายคิวรีหลักสำหรับการจับเวลาประสิทธิภาพคือ gl.TIME_ELAPSED เมื่อคิวรีประเภทนี้ทำงานอยู่ GPU จะวัดเวลาที่ผ่านไปบนไทม์ไลน์ของ GPU ระหว่างการเรียก beginQuery และ endQuery

การทำความเข้าใจ Query Targets

แม้ว่า gl.TIME_ELAPSED จะเกี่ยวข้องมากที่สุดสำหรับการทำโปรไฟล์ประสิทธิภาพ แต่ WebGL (และ OpenGL ES ที่เป็นพื้นฐาน) ก็รองรับเป้าหมายคิวรีอื่นๆ:

• gl.SAMPLES_PASSED: คิวรีประเภทนี้นับจำนวนแฟรกเมนต์ที่ผ่านการทดสอบความลึก (depth) และสเตนซิล (stencil) มีประโยชน์สำหรับ occlusion queries และการทำความเข้าใจอัตราการทิ้งแฟรกเมนต์ในช่วงต้น
• gl.ANY_SAMPLES_ PASSIVE (มีใน WebGL2): คล้ายกับ SAMPLES_PASSED แต่อาจมีประสิทธิภาพมากกว่าในฮาร์ดแวร์บางตัว

สำหรับวัตถุประสงค์ของคู่มือนี้ เราจะมุ่งเน้นไปที่ gl.TIME_ELAPSED เนื่องจากเป็นการจับเวลาประสิทธิภาพโดยตรง

การนำไปใช้จริง: การจับเวลาการเรนเดอร์

ขั้นตอนการทำงานสำหรับการใช้ WebGL Query Objects เพื่อวัดเวลาของการเรนเดอร์มีดังนี้:

1. สร้าง Query Object: ก่อนที่คุณจะเริ่มวัด ให้สร้าง query object ขึ้นมาก่อน เป็นแนวทางปฏิบัติที่ดีในการสร้างหลายๆ อันหากคุณต้องการวัดการทำงานที่แตกต่างกันหลายอย่างพร้อมกันหรือตามลำดับโดยไม่บล็อก GPU เพื่อรอผลลัพธ์
2. เริ่มคิวรี: เรียก gl.beginQuery(gl.TIME_ELAPSED, query) ก่อนคำสั่งเรนเดอร์ที่คุณต้องการวัด
3. ทำการเรนเดอร์: รัน WebGL draw calls, shader dispatches หรือการทำงานอื่นๆ ที่ผูกกับ GPU
4. สิ้นสุดคิวรี: เรียก gl.endQuery(gl.TIME_ELAPSED) ทันทีหลังจากคำสั่งเรนเดอร์
5. ดึงผลลัพธ์: ในเวลาต่อมา (ควรจะเป็นหลังจากผ่านไปสองสามเฟรมเพื่อให้ GPU ประมวลผลเสร็จสิ้น หรือโดยการตรวจสอบความพร้อมใช้งาน) ให้เรียก gl.getQueryParameter(query, gl.QUERY_RESULT) เพื่อรับเวลาที่ผ่านไป

ลองดูตัวอย่างโค้ดจริง สมมติว่าเราต้องการวัดเวลาที่ใช้ในการเรนเดอร์ฉากที่ซับซ้อนซึ่งมีออบเจ็กต์และเชเดอร์หลายตัว

ตัวอย่างโค้ด: การวัดเวลาการเรนเดอร์ฉาก

            let timeQuery;

function initQueries(gl) {
    timeQuery = gl.createQuery();
}

function renderScene(gl, program, modelViewMatrix, projectionMatrix) {
    // --- Start timing this rendering operation ---
    gl.beginQuery(gl.TIME_ELAPSED, timeQuery);

    // --- Your typical rendering code --- 
    gl.useProgram(program);

    // Setup matrices and uniforms...
    const mvMatrixLoc = gl.getUniformLocation(program, "uModelViewMatrix");
    gl.uniformMatrix4fv(mvMatrixLoc, false, modelViewMatrix);

    const pMatrixLoc = gl.getUniformLocation(program, "uProjectionMatrix");
    gl.uniformMatrix4fv(pMatrixLoc, false, projectionMatrix);

    // Bind buffers, set attributes, draw calls...
    // Example: gl.bindBuffer(gl.ARRAY_BUFFER, vertexBuffer);
    // Example: gl.vertexAttribPointer(...);
    // Example: gl.drawArrays(gl.TRIANGLES, 0, numVertices);
    
    // Simulate some rendering work
    for (let i = 0; i < 100000; ++i) {
        // Placeholder for some intensive GPU operations
    }

    // --- End timing this rendering operation ---
    gl.endQuery(gl.TIME_ELAPSED);

    // --- Later, or in the next frame, retrieve the result ---
    // It's important NOT to immediately call getQueryParameter if you want 
    // to avoid synchronizing the CPU and GPU, which can hurt performance.
    // Instead, check if the result is available or defer retrieval.
}

function processQueryResults(gl) {
    if (gl.getQueryParameter(timeQuery, gl.GET_QUERY_   PROPERTY) === true) {
        const elapsedNanos = gl.getQueryParameter(timeQuery, gl.QUERY_RESULT);
        const elapsedMillis = elapsedNanos / 1e6; // Convert nanoseconds to milliseconds
        console.log(`GPU rendering took: ${elapsedMillis.toFixed(2)} ms`);

        // You might want to reset the query or use a new one for the next measurement.
        // For simplicity in this example, we might re-use it, but in a real app, 
        // consider managing a pool of queries.
        gl.deleteQuery(timeQuery); // Clean up
        timeQuery = gl.createQuery(); // Create a new one for next frame
    }
}

// In your animation loop:
// function animate() {
//     requestAnimationFrame(animate);
//     // ... setup matrices ...
//     renderScene(gl, program, mvMatrix, pMatrix);
//     processQueryResults(gl);
//     // ... other rendering and processing ...
// }

// initQueries(gl);
// animate();

            

              
                Copy
              
            
          

ข้อควรพิจารณาที่สำคัญสำหรับการใช้คิวรี

1. ลักษณะการทำงานแบบอะซิงโครนัส (Asynchronous Nature): สิ่งที่สำคัญที่สุดในการใช้ query objects คือการทำความเข้าใจว่า GPU ทำงานแบบอะซิงโครนัส เมื่อคุณเรียก gl.endQuery(), GPU อาจยังไม่ได้ประมวลผลคำสั่งระหว่าง beginQuery() และ endQuery() เสร็จสิ้น ในทำนองเดียวกัน เมื่อคุณเรียก gl.getQueryParameter(query, gl.QUERY_RESULT) ผลลัพธ์อาจจะยังไม่พร้อม

2. การซิงโครไนซ์และการบล็อก (Synchronization and Blocking): หากคุณเรียก gl.getQueryParameter(query, gl.QUERY_RESULT) ทันทีหลังจาก gl.endQuery() และผลลัพธ์ยังไม่พร้อม การเรียกนั้นจะบล็อก CPU จนกว่า GPU จะทำงานในคิวรีนั้นเสร็จสิ้น สิ่งนี้เรียกว่า การซิงโครไนซ์ CPU-GPU และสามารถลดประสิทธิภาพลงอย่างรุนแรง ซึ่งทำลายประโยชน์ของการประมวลผล GPU แบบอะซิงโครนัส เพื่อหลีกเลี่ยงปัญหานี้:

• หน่วงเวลาการดึงข้อมูล (Defer Retrieval): ดึงผลลัพธ์ของคิวรีในอีกสองสามเฟรมถัดไป
• ตรวจสอบความพร้อมใช้งาน (Check Availability): ใช้ gl.getQueryParameter(query, gl.GET_QUERY_ PROPERTY) เพื่อตรวจสอบว่าผลลัพธ์พร้อมใช้งานหรือไม่ก่อนที่จะร้องขอ ซึ่งจะคืนค่าเป็น true หากผลลัพธ์พร้อมแล้ว
• ใช้คิวรีหลายตัว (Use Multiple Queries): สำหรับการวัดเวลาของเฟรม เป็นเรื่องปกติที่จะใช้ query object สองตัว เริ่มวัดด้วยคิวรี A ที่จุดเริ่มต้นของเฟรม ในเฟรมถัดไป ให้ดึงผลลัพธ์จากคิวรี A (ซึ่งเริ่มในเฟรมก่อนหน้า) และเริ่มวัดด้วยคิวรี B ทันที สิ่งนี้จะสร้างไปป์ไลน์และหลีกเลี่ยงการบล็อกโดยตรง

3. ขีดจำกัดของคิวรี (Query Limits): GPU ส่วนใหญ่มีขีดจำกัดจำนวนคิวรีที่สามารถทำงานค้างอยู่ได้ เป็นแนวปฏิบัติที่ดีในการจัดการ query objects อย่างระมัดระวัง โดยนำกลับมาใช้ใหม่หรือลบเมื่อไม่ต้องการอีกต่อไป WebGL2 มักจะมี gl.MAX_ SERVER_ WAIT_ TIMEOUT_ NON_BLOCKING ซึ่งสามารถสอบถามเพื่อทำความเข้าใจขีดจำกัดได้

4. การรีเซ็ต/การใช้ซ้ำคิวรี (Query Reset/Reuse): โดยทั่วไปแล้ว query objects จำเป็นต้องถูกรีเซ็ตหรือลบและสร้างขึ้นใหม่หากคุณต้องการใช้ซ้ำสำหรับการวัดครั้งต่อไป ตัวอย่างข้างต้นสาธิตการลบและสร้างคิวรีใหม่

การทำโปรไฟล์ขั้นตอนการเรนเดอร์เฉพาะส่วน

การวัดเวลา GPU ของทั้งเฟรมเป็นจุดเริ่มต้นที่ดี แต่เพื่อการเพิ่มประสิทธิภาพอย่างแท้จริง คุณต้องทำโปรไฟล์ส่วนเฉพาะของไปป์ไลน์การเรนเดอร์ของคุณ ซึ่งจะช่วยให้คุณระบุได้ว่าส่วนประกอบใดมีค่าใช้จ่ายสูงที่สุด

พิจารณาพื้นที่ทั่วไปเหล่านี้เพื่อทำโปรไฟล์:

• การประมวลผลเชเดอร์ (Shader Execution): วัดเวลาที่ใช้ใน fragment shaders หรือ vertex shaders ซึ่งมักจะทำโดยการจับเวลา draw calls ที่ใช้เชเดอร์ที่ซับซ้อนเป็นพิเศษ
• การอัปโหลด/การผูกเท็กซ์เจอร์ (Texture Uploads/Bindings): แม้ว่าการอัปโหลดเท็กซ์เจอร์ส่วนใหญ่จะเป็นการทำงานของ CPU ที่ถ่ายโอนข้อมูลไปยังหน่วยความจำ GPU แต่การสุ่มตัวอย่างในภายหลังอาจถูกจำกัดโดยแบนด์วิดท์ของหน่วยความจำ การจับเวลาการวาดจริงที่ใช้เท็กซ์เจอร์เหล่านี้สามารถเปิดเผยปัญหาดังกล่าวทางอ้อมได้
• การทำงานของเฟรมบัฟเฟอร์ (Framebuffer Operations): หากคุณใช้การเรนเดอร์หลายรอบด้วยเฟรมบัฟเฟอร์นอกหน้าจอ (offscreen framebuffers) (เช่น สำหรับ deferred rendering, เอฟเฟกต์หลังการประมวลผล) การจับเวลาแต่ละรอบสามารถเน้นการทำงานที่มีค่าใช้จ่ายสูงได้
• Compute Shaders (WebGL2): สำหรับงานที่ไม่เกี่ยวข้องโดยตรงกับการแรสเตอร์ Compute Shaders ให้การประมวลผลแบบขนานสำหรับวัตถุประสงค์ทั่วไป การจับเวลา compute dispatches มีความสำคัญอย่างยิ่งสำหรับปริมาณงานเหล่านี้

ตัวอย่าง: การทำโปรไฟล์เอฟเฟกต์หลังการประมวลผล (Post-Processing Effect)

สมมติว่าคุณมีเอฟเฟกต์แสงฟุ้ง (bloom) ที่ใช้เป็นขั้นตอนหลังการประมวลผล โดยทั่วไปจะเกี่ยวข้องกับการเรนเดอร์ฉากไปยังเท็กซ์เจอร์ จากนั้นใช้เอฟเฟกต์แสงฟุ้งในหนึ่งรอบหรือมากกว่า ซึ่งมักใช้การเบลอแบบเกาส์เซียนที่แยกกันได้ (separable Gaussian blurs)

            let sceneQuery, bloomPass1Query, bloomPass2Query;

function initQueries(gl) {
    sceneQuery = gl.createQuery();
    bloomPass1Query = gl.createQuery();
    bloomPass2Query = gl.createQuery();
}

function renderFrame(gl, sceneProgram, bloomProgram, sceneTexture, bloomTexture1, bloomTexture2) {
    // --- Render Scene to main framebuffer (or an intermediate texture) ---
    gl.beginQuery(gl.TIME_ELAPSED, sceneQuery);
    gl.useProgram(sceneProgram);
    // ... draw scene geometry ...
    gl.endQuery(gl.TIME_ELAPSED);

    // --- Render bloom pass 1 (e.g., horizontal blur) ---
    // Bind bloomTexture1 as input, render to bloomTexture2 (or FBO)
    gl.bindFramebuffer(gl.FRAMEBUFFER, bloomFBO1);
    gl.useProgram(bloomProgram);
    // ... set bloom uniforms (direction, intensity), draw quad ...
    gl.beginQuery(gl.TIME_ELAPSED, bloomPass1Query);
    gl.drawArrays(gl.TRIANGLES, 0, 6); // Assuming fullscreen quad
    gl.endQuery(gl.TIME_ELAPSED);
    gl.bindFramebuffer(gl.FRAMEBUFFER, null); // Unbind FBO

    // --- Render bloom pass 2 (e.g., vertical blur) ---
    // Bind bloomTexture2 as input, render to final framebuffer
    gl.bindFramebuffer(gl.FRAMEBUFFER, null); // Main framebuffer
    gl.useProgram(bloomProgram);
    // ... set bloom uniforms (direction, intensity), draw quad ...
    gl.beginQuery(gl.TIME_ELAPSED, bloomPass2Query);
    gl.drawArrays(gl.TRIANGLES, 0, 6); // Assuming fullscreen quad
    gl.endQuery(gl.TIME_ELAPSED);

    // --- Later, process results --- 
    // It's better to process results in the next frame or after a few frames
}

function processAllQueryResults(gl) {
    if (gl.getQueryParameter(sceneQuery, gl.GET_QUERY_   PROPERTY)) {
        const elapsedNanos = gl.getQueryParameter(sceneQuery, gl.QUERY_RESULT);
        console.log(`GPU Scene Render Time: ${elapsedNanos / 1e6} ms`);
    }
    if (gl.getQueryParameter(bloomPass1Query, gl.GET_QUERY_   PROPERTY)) {
        const elapsedNanos = gl.getQueryParameter(bloomPass1Query, gl.QUERY_RESULT);
        console.log(`GPU Bloom Pass 1 Time: ${elapsedNanos / 1e6} ms`);
    }
    if (gl.getQueryParameter(bloomPass2Query, gl.GET_QUERY_   PROPERTY)) {
        const elapsedNanos = gl.getQueryParameter(bloomPass2Query, gl.QUERY_RESULT);
        console.log(`GPU Bloom Pass 2 Time: ${elapsedNanos / 1e6} ms`);
    }
    // Clean up and recreate queries for the next frame
    gl.deleteQuery(sceneQuery);
    gl.deleteQuery(bloomPass1Query);
    gl.deleteQuery(bloomPass2Query);
    initQueries(gl);
}

// In animation loop:
// renderFrame(...);
// processAllQueryResults(gl); // (Ideally deferred)

            

              
                Copy
              
            
          

ด้วยการทำโปรไฟล์แต่ละขั้นตอน คุณจะเห็นได้ว่าการเรนเดอร์ฉากเองเป็นคอขวด หรือเอฟเฟกต์หลังการประมวลผลใช้เวลา GPU มากเกินสัดส่วน ข้อมูลนี้มีค่าอย่างยิ่งในการตัดสินใจว่าจะมุ่งเน้นความพยายามในการเพิ่มประสิทธิภาพไปที่ใด

ข้อผิดพลาดด้านประสิทธิภาพทั่วไปและวิธีที่ Query Objects ช่วยได้

เรามาสำรวจปัญหาประสิทธิภาพทั่วไปของ WebGL และวิธีที่ query objects สามารถช่วยวินิจฉัยปัญหาเหล่านั้นได้:

1. การวาดทับ (Overdraw)

คืออะไร: Overdraw เกิดขึ้นเมื่อพิกเซลเดียวกันถูกเรนเดอร์หลายครั้งในเฟรมเดียว ตัวอย่างเช่น การเรนเดอร์ออบเจ็กต์ที่ซ่อนอยู่หลังออบเจ็กต์อื่นโดยสิ้นเชิง หรือการเรนเดอร์ออบเจ็กต์โปร่งใสหลายครั้ง

Query objects ช่วยได้อย่างไร: แม้ว่า query objects จะไม่ได้วัด overdraw โดยตรงเหมือนเครื่องมือดีบักแบบเห็นภาพ แต่ก็สามารถเปิดเผยผลกระทบทางอ้อมได้ หาก fragment shader ของคุณมีค่าใช้จ่ายสูง และคุณมี overdraw มาก เวลา GPU ทั้งหมดสำหรับ draw calls ที่เกี่ยวข้องจะสูงกว่าที่คาดไว้ หากส่วนสำคัญของเวลาเฟรมของคุณหมดไปกับ fragment shaders และการลด overdraw (เช่น ผ่านการคัดกรองที่ดีขึ้นหรือการเรียงลำดับความลึก) นำไปสู่การลดลงของเวลา GPU อย่างเห็นได้ชัดสำหรับรอบเหล่านั้น แสดงว่า overdraw เป็นปัจจัยหนึ่ง

2. เชเดอร์ที่มีค่าใช้จ่ายสูง (Expensive Shaders)

คืออะไร: เชเดอร์ที่ดำเนินการคำสั่งจำนวนมาก การดำเนินการทางคณิตศาสตร์ที่ซับซ้อน การค้นหาเท็กซ์เจอร์มากเกินไป หรือการแตกแขนงจำนวนมากอาจมีค่าใช้จ่ายในการคำนวณสูง

Query objects ช่วยได้อย่างไร: จับเวลา draw calls ที่ใช้เชเดอร์เหล่านี้โดยตรง หาก draw call ใดโดยเฉพาะใช้เปอร์เซ็นต์ของเวลาเฟรมของคุณอย่างสม่ำเสมอ แสดงว่าเป็นตัวบ่งชี้ที่ชัดเจนว่าเชเดอร์นั้นต้องการการเพิ่มประสิทธิภาพ (เช่น ลดความซับซ้อนของการคำนวณ ลดการดึงข้อมูลเท็กซ์เจอร์ ใช้ uniform ที่มีความแม่นยำต่ำลง)

3. Draw Calls มากเกินไป (Too Many Draw Calls)

คืออะไร: แต่ละ draw call มีค่าใช้จ่ายบางอย่างทั้งบน CPU และ GPU การส่ง draw calls ขนาดเล็กจำนวนมากเกินไปอาจกลายเป็นคอขวดของ CPU แต่แม้ในฝั่ง GPU การสลับบริบทและการเปลี่ยนแปลงสถานะก็มีค่าใช้จ่าย

Query objects ช่วยได้อย่างไร: แม้ว่าค่าใช้จ่ายของ draw call มักจะเป็นปัญหาของ CPU แต่ GPU ก็ยังต้องประมวลผลการเปลี่ยนแปลงสถานะ หากคุณมีออบเจ็กต์จำนวนมากที่อาจรวมกันได้ (เช่น วัสดุเดียวกัน เชเดอร์เดียวกัน) และการทำโปรไฟล์แสดงให้เห็นว่า draw calls สั้นๆ ที่แตกต่างกันจำนวนมากส่งผลต่อเวลาการเรนเดอร์โดยรวม ให้พิจารณาใช้การรวมกลุ่ม (batching) หรือการทำอินสแตนซ์ (instancing) เพื่อลดจำนวน draw calls

4. ข้อจำกัดแบนด์วิดท์ของเท็กซ์เจอร์ (Texture Bandwidth Limitations)

คืออะไร: GPU จำเป็นต้องดึงข้อมูลเท็กเซล (texel) จากหน่วยความจำ หากข้อมูลที่กำลังสุ่มตัวอย่างมีขนาดใหญ่ หรือรูปแบบการเข้าถึงไม่มีประสิทธิภาพ (เช่น เท็กซ์เจอร์ที่ไม่ใช่กำลังสอง, การตั้งค่าการกรองที่ไม่ถูกต้อง, เท็กซ์เจอร์ขนาดใหญ่) อาจทำให้แบนด์วิดท์ของหน่วยความจำอิ่มตัวและกลายเป็นคอขวดได้

Query objects ช่วยได้อย่างไร: สิ่งนี้วินิจฉัยโดยตรงได้ยากกว่าด้วยคิวรีเวลาที่ผ่านไป อย่างไรก็ตาม หากคุณสังเกตเห็นว่า draw calls ที่ใช้เท็กซ์เจอร์ขนาดใหญ่หรือจำนวนมากนั้นช้าเป็นพิเศษ และการเพิ่มประสิทธิภาพรูปแบบเท็กซ์เจอร์ (เช่น การใช้รูปแบบที่บีบอัดเช่น ASTC หรือ ETC2) การลดความละเอียดของเท็กซ์เจอร์ หรือการปรับปรุง UV mapping ไม่ได้ช่วยปรับปรุงเวลา GPU อย่างมีนัยสำคัญ อาจชี้ไปที่ข้อจำกัดของแบนด์วิดท์

5. ความแม่นยำของ Fragment Shader (Fragment Shader Precision)

คืออะไร: การใช้ความแม่นยำสูง (เช่น `highp`) สำหรับตัวแปรทั้งหมดใน fragment shaders โดยเฉพาะอย่างยิ่งเมื่อความแม่นยำต่ำกว่า (`mediump`, `lowp`) ก็เพียงพอแล้ว อาจทำให้การทำงานช้าลงใน GPU บางตัว โดยเฉพาะบนมือถือ

Query objects ช่วยได้อย่างไร: หากการทำโปรไฟล์แสดงให้เห็นว่าการประมวลผล fragment shader เป็นคอขวด ให้ทดลองลดความแม่นยำสำหรับการคำนวณระดับกลางหรือผลลัพธ์สุดท้ายที่ไม่ส่งผลต่อความคมชัดของภาพมากนัก สังเกตผลกระทบต่อเวลา GPU ที่วัดได้

WebGL2 และความสามารถของคิวรีที่ได้รับการปรับปรุง

WebGL2 ซึ่งใช้พื้นฐานจาก OpenGL ES 3.0 ได้นำเสนอการปรับปรุงหลายอย่างที่เป็นประโยชน์สำหรับการทำโปรไฟล์ประสิทธิภาพ:

• gl.ANY_SAMPLES_ PASSIVE: ทางเลือกแทน gl.SAMPLES_PASSED ซึ่งอาจมีประสิทธิภาพมากกว่า
• Query Buffers: WebGL2 ช่วยให้คุณสามารถสะสมผลลัพธ์ของคิวรีลงในบัฟเฟอร์ ซึ่งอาจมีประสิทธิภาพมากกว่าสำหรับการรวบรวมตัวอย่างจำนวนมากเมื่อเวลาผ่านไป
• Timestamp Queries: แม้ว่าจะไม่สามารถใช้งานได้โดยตรงเป็น API มาตรฐานของ WebGL สำหรับการจับเวลาตามต้องการ แต่ส่วนขยายอาจมีฟังก์ชันนี้ อย่างไรก็ตาม TIME_ELAPSED ยังคงเป็นเครื่องมือหลักในการวัดระยะเวลาของคำสั่ง

สำหรับงานทำโปรไฟล์ประสิทธิภาพทั่วไปส่วนใหญ่ ฟังก์ชันหลักของ gl.TIME_ELAPSED ยังคงมีความสำคัญที่สุดและมีให้ใช้งานทั้งใน WebGL1 และ WebGL2

แนวทางปฏิบัติที่ดีที่สุดสำหรับการทำโปรไฟล์ประสิทธิภาพ

เพื่อให้ได้ประโยชน์สูงสุดจาก WebGL Query Objects และได้รับข้อมูลเชิงลึกด้านประสิทธิภาพที่มีความหมาย ให้ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดเหล่านี้:

• ทำโปรไฟล์บนอุปกรณ์เป้าหมาย (Profile on Target Devices): ลักษณะการทำงานของประสิทธิภาพอาจแตกต่างกันอย่างมาก ควรทำโปรไฟล์แอปพลิเคชันของคุณบนอุปกรณ์และระบบปฏิบัติการที่หลากหลายซึ่งกลุ่มเป้าหมายของคุณใช้ สิ่งที่ทำงานเร็วบนเดสก์ท็อประดับไฮเอนด์อาจช้าจนรับไม่ได้บนแท็บเล็ตระดับกลางหรือสมาร์ทโฟนรุ่นเก่า
• แยกการวัดผล (Isolate Measurements): เมื่อทำโปรไฟล์ส่วนประกอบเฉพาะ ตรวจสอบให้แน่ใจว่าการทำงานที่หนักหน่วงอื่นๆ ไม่ได้ทำงานพร้อมกัน เนื่องจากอาจทำให้ผลลัพธ์ของคุณบิดเบือนได้
• หาค่าเฉลี่ยของผลลัพธ์ (Average Results): การวัดเพียงครั้งเดียวอาจมีสัญญาณรบกวน ควรหาค่าเฉลี่ยของผลลัพธ์จากหลายๆ เฟรมเพื่อให้ได้เมตริกประสิทธิภาพที่เสถียรและเป็นตัวแทนมากขึ้น
• ใช้ Query Objects หลายตัวสำหรับ Frame Pipelining: เพื่อหลีกเลี่ยงการซิงโครไนซ์ CPU-GPU ให้ใช้อย่างน้อยสอง query objects ในลักษณะสลับกัน (ping-pong) ในขณะที่เฟรม N กำลังถูกเรนเดอร์ ให้ดึงผลลัพธ์สำหรับเฟรม N-1
• หลีกเลี่ยงการสอบถามทุกเฟรมสำหรับเวอร์ชันโปรดักชัน (Avoid Querying Every Frame for Production): Query objects มีค่าใช้จ่ายบางอย่าง แม้ว่าจะมีค่าอย่างยิ่งสำหรับการพัฒนาและดีบัก แต่ให้พิจารณาปิดการใช้งานหรือลดความถี่ของการสอบถามอย่างกว้างขวางในบิลด์โปรดักชันเพื่อลดผลกระทบด้านประสิทธิภาพที่อาจเกิดขึ้น
• ใช้ร่วมกับเครื่องมืออื่นๆ (Combine with Other Tools): WebGL Query Objects มีประสิทธิภาพ แต่ไม่ใช่เครื่องมือเดียว ใช้เครื่องมือสำหรับนักพัฒนาของเบราว์เซอร์ (เช่น แท็บ Performance ของ Chrome DevTools ซึ่งสามารถแสดงการเรียก WebGL และเวลาของเฟรม) และเครื่องมือทำโปรไฟล์เฉพาะของผู้จำหน่าย GPU (หากเข้าถึงได้) เพื่อให้ได้มุมมองที่ครอบคลุมยิ่งขึ้น
• มุ่งเน้นที่คอขวด (Focus on Bottlenecks): อย่าเพิ่มประสิทธิภาพโค้ดที่ไม่ใช่คอขวดด้านประสิทธิภาพ ใช้ข้อมูลจากการทำโปรไฟล์เพื่อระบุส่วนที่ช้าที่สุดของแอปพลิเคชันของคุณและมุ่งเน้นความพยายามของคุณที่นั่น
• คำนึงถึง CPU เทียบกับ GPU (Be Mindful of CPU vs. GPU): จำไว้ว่า query objects วัดเวลาของ GPU หากแอปพลิเคชันของคุณช้าเนื่องจากงานที่ผูกกับ CPU (เช่น การจำลองฟิสิกส์ที่ซับซ้อน, การคำนวณ JavaScript ที่หนักหน่วง, การเตรียมข้อมูลที่ไม่มีประสิทธิภาพ) query objects จะไม่เปิดเผยสิ่งนี้โดยตรง คุณจะต้องใช้เทคนิคการทำโปรไฟล์อื่นๆ สำหรับฝั่ง CPU

ข้อควรพิจารณาในระดับโลกสำหรับประสิทธิภาพ WebGL

เมื่อตั้งเป้าหมายไปที่ผู้ชมทั่วโลก การเพิ่มประสิทธิภาพ WebGL จะมีมิติเพิ่มเติม:

• ความหลากหลายของอุปกรณ์ (Device Diversity): ดังที่ได้กล่าวไปแล้ว ฮาร์ดแวร์มีความแตกต่างกันอย่างมาก พิจารณาแนวทางแบบแบ่งระดับสำหรับคุณภาพกราฟิก โดยอนุญาตให้ผู้ใช้บนอุปกรณ์ที่มีประสิทธิภาพน้อยกว่าสามารถปิดใช้งานเอฟเฟกต์บางอย่างหรือใช้แอสเซทที่มีความละเอียดต่ำกว่าได้ การทำโปรไฟล์ช่วยระบุว่าคุณสมบัติใดที่สิ้นเปลืองทรัพยากรมากที่สุด
• ความล่าช้าของเครือข่าย (Network Latency): แม้ว่าจะไม่เกี่ยวข้องโดยตรงกับการจับเวลาของ GPU แต่การดาวน์โหลดแอสเซทของ WebGL (โมเดล, เท็กซ์เจอร์, เชเดอร์) อาจส่งผลต่อเวลาในการโหลดเริ่มต้นและประสิทธิภาพที่รับรู้ได้ ตรวจสอบให้แน่ใจว่าแอสเซทได้รับการจัดแพ็กเกจและส่งมอบอย่างมีประสิทธิภาพ
• เวอร์ชันของเบราว์เซอร์และไดรเวอร์ (Browser and Driver Versions): การใช้งานและประสิทธิภาพของ WebGL อาจแตกต่างกันไปในแต่ละเบราว์เซอร์และไดรเวอร์ GPU พื้นฐาน ทดสอบบนเบราว์เซอร์หลักๆ (Chrome, Firefox, Safari, Edge) และพิจารณาว่าอุปกรณ์รุ่นเก่าอาจใช้ไดรเวอร์ที่ล้าสมัย
• การเข้าถึง (Accessibility): ประสิทธิภาพส่งผลต่อการเข้าถึง ประสบการณ์ที่ราบรื่นเป็นสิ่งสำคัญสำหรับผู้ใช้ทุกคน รวมถึงผู้ที่อาจไวต่อการเคลื่อนไหวหรือต้องการเวลาในการโต้ตอบกับเนื้อหามากขึ้น

สรุป

WebGL Query Objects เป็นเครื่องมือที่ขาดไม่ได้สำหรับนักพัฒนาที่จริงจังกับการเพิ่มประสิทธิภาพแอปพลิเคชันกราฟิก 3D สำหรับเว็บ ด้วยการให้การเข้าถึงข้อมูลเวลาของ GPU โดยตรงในระดับต่ำ จึงช่วยให้คุณก้าวข้ามการคาดเดาและระบุคอขวดที่แท้จริงในไปป์ไลน์การเรนเดอร์ของคุณได้

การเรียนรู้ธรรมชาติแบบอะซิงโครนัส การใช้แนวทางปฏิบัติที่ดีที่สุดสำหรับการวัดผลและการดึงข้อมูล และการใช้เพื่อทำโปรไฟล์ขั้นตอนการเรนเดอร์เฉพาะส่วน จะช่วยให้คุณสามารถ:

• พัฒนาแอปพลิเคชัน WebGL ที่มีประสิทธิภาพและประสิทธิผลมากขึ้น
• รับประกันประสบการณ์ผู้ใช้ที่สม่ำเสมอและมีคุณภาพสูงบนอุปกรณ์ที่หลากหลายทั่วโลก
• ตัดสินใจอย่างมีข้อมูลเกี่ยวกับสถาปัตยกรรมการเรนเดอร์และกลยุทธ์การเพิ่มประสิทธิภาพของคุณ

เริ่มรวม WebGL Query Objects เข้ากับขั้นตอนการพัฒนาของคุณตั้งแต่วันนี้ และปลดล็อกศักยภาพสูงสุดของประสบการณ์เว็บ 3D ของคุณ

ขอให้สนุกกับการทำโปรไฟล์!